I feel like we need to get a type checker going to know what works and doesnt

I feel like we need to get a type checker going to know what works and doesnt

Yes, but we then also need a minimal an implementation to check against :)

I feel like we need to get a type checker going to know what works and doesnt

Yes, but we then also need a minimal implementation to check against :)

does it have to be minimal? would a fork of pint (or another module) work?

would a fork of pint (or another module) work?

yeah, I think so!

I've added some tentative suggestions but I'm not sure that they are correct — @jorenham do my suggestions look closer to what we would want here?

My mental typechecker did not report any errors 👌🏻

I feel like we need to get a type checker going to know what works and doesnt

Exactly; writing annotations without a type-checker is like programming without a compiler or interpreter

type checkers are happy! Any opinions on #5 (comment) @nstarman @neutrinoceros ?

alright, let's get this in, we can always revisit other methods as and when need arises. thanks all!

oh I meant to ask if we want to keep rpow

I think so. If we can do x ** q.value, we should also be able to do x ** q.

that only makes sense for a unitless quantity, you shouldn't be able to do 2 ** Quantity(2, "m"). I think its reasonable for a library to implement this or not implement it

ah yeah, good point, we should probably remove it then

that only makes sense for a unitless quantity, you shouldn't be able to do 2 ** Quantity(2, "m"). I think its reasonable for a library to implement this or not implement it

not sure if it's a thing, but maybe it makes sense for logarithmic units like decibels?

Agreed. This feels like an API vs implementation issue. If you have access to the runtime, which we do not, then you can distinguish between dimensionful and dimensionless quantities.